Working with Search Page Layouts : Modify the Search Results Presentation (part 2)

7.4.5. Viewing and Searching for Ratings

Having performed all the changes required for ratings to show up should yield a result page looking similar to Figure 5. It gives the user the possibility to select or ignore a specific search result based on recommendations from other people in your organization directly from the search results list.

This example of showing ratings is very basic. More advanced graphical templates can be applied to further enhance the user experience.

Figure 5. Ratings showing in search results

It is also possible to search for results with a rating higher, lower, or equal to a specific value. This can be done by simply searching for the property.

Rating>3

Rating<4

Rating=3,5

This is very useful for administrators to find documents with poor content that requires updating or deletion. It is equally useful for users to be able to refine or filter by documents that have a certain minimum ranking to avoid getting irrelevant results as seen in Figure 6.

Figure 6. Search result based on Rating property and displaying result rating.

6. Removing Metadata from Search Results

Removing metadata is usually a trivial task to perform. All that is needed is to remove the property from the XSL template. For example, there might be a requirement for the CreatedBy property to be removed.

To do this, open up the Search Core Results XSL template. Then find and remove or comment out the relevant call template section (shown here in its default form).

<xsl:call-template name=”DisplayAuthors”>

<xsl:with-param name=”author” select=” author” />

</xsl:call-template>

					  

After the XSL is saved, the author or CreatedBy property no longer shows in search results.

7. Changing Click Action of Search Results

Normal SharePoint behavior when clicking a search result item is to open the source directly. For web sites, this makes good sense but not so much for a lot of document types.

A typical scenario of what the user expects when clicking a document search result is to open a page that displays additional information about that particular search result and possibly a list of available actions and versions. This is available as an option on the search result item drop-down but not the default one when clicking.

The problem is the context switch from SharePoint to the native application of the search result document. The user can either see the loading screen of the document's native application (Figure 7) or the document details page in SharePoint, which allows the user to do check-outs, go through version history, and obviously open the document.

Figure 7. Standard click action for document results

The default SharePoint behavior to open the document without warning is a design choice aimed at the user knowing that the document is the right one and wanting to edit or read it. In a search context, this often is not the case.

In those cases, a different action is desired for the search results when clicked. The goal here is to allow the user to make a conscious choice about what to do with the search result.

Other side benefits are that the user doesn't lock the document if it is located on a file share without intent and also to reduce the network load of opening many documents without reason.

To accommodate such a behavior for documents, the default click action can be changed to redirect to the View Properties page rather than opening the document. This requires some rewiring of the search results Web Part.

8. Creating a Managed ID Property

Create a managed property and give it a suitable name, for instance SearchResultID. Then map it to the crawled property called ows_ID with the type Integer. Make sure to include the crawled property in the index.

In the Search service application, go to Federated Locations and open the location named Local Search Results. Here the new managed property can be added to the properties of the Core Search Results Display Metadata field like this:

<Column Name="SearchResultID"/>

When done, do a full crawl to make the property data available in search results.

In the Core Search Results Display Metadata, now click the XSL editor and modify the XSL to include the newly added managed property SearchResultID in the Result template match.

<xsl:variable name="id" select="id"/>
<xsl:variable name="currentId" select="concat($IdPrefix,$id)"/>
<xsl:variable name="url" select="url"/>
<xsl:variable name="searchresultid" select="searchresultid"/>

Now the click action for documents is to be changed. It will be configured to redirect to the View Properties page with the value of the SearchResultID property transferred to the View Properties page as a URL parameter.

Fortunately there exists an IsDocument property that can be used to check if the click action should be rewired. To accomplish this, find the following XSL from the template.

<xsl:attribute name="href">
  <xsl:value-of select="$url"/>
</xsl:attribute>

Insert this XSL just after the foregoing. This XSL uses a conditional statement to check if the result is a document. If it is a document, then the href attribute is set to the View Properties page with the SearchResultID added as a URL argument. Otherwise the href value is left unchanged.

<xsl:attribute name="href">
      <xsl:value-of select="$url"/>
    </xsl:attribute>
<xsl:choose>
  <xsl:when test="isdocument='True'">
    <xsl:attribute name="href">
      <xsl:value-of select="concat(sitename,'/Forms/DispForm.aspx?id=',$searchresultid)"/>
    </xsl:attribute>
  </xsl:when>
</xsl:choose>

					  

Now the result redirects to the View Properties page for document results (Figure 8) and to the URL destination for other types of results. It should be noted that this works for document libraries.

Figure 8. Custom click action for document results